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Abstract 


This document describes a network diagnostic tool called PROBE. 
PROBE is similar to PING in that it can be used to query the status 


of a probed interface, 


but it differs from PING in that it does not 


require bidirectional connectivity between the probing and probed 


interfaces. 


between the probing interface and a proxy interface. 
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1. Introduction 


Network operators use PING [RFC2151] to test bidirectional 
connectivity between two interfaces. For the purposes of this 
document, these interfaces are called the probing and probed 
interfaces. PING sends an ICMP [RFC792] [RFC4443] Echo Request 
message from the probing interface to the probed interface. The 
probing interface resides on a probing node while the probed 
interface resides on a probed node. 


If the probed interface receives the ICMP Echo Request message, it 
returns an ICMP Echo Reply. When the probing interface receives the 
ICMP Echo Reply, it has verified bidirectional connectivity between 
the probing and probed interfaces. Specifically, it has verified 
that: 


o The probing node can reach the probed interface. 
o The probed interface is active. 

o The probed node can reach the probing interface. 
o The probing interface is active. 


This document describes a network diagnostic tool called PROBE. 
PROBE is similar to PING in that it can be used to query the status 
of a probed interface, but it differs from PING in that it does not 
require bidirectional connectivity between the probing and probed 
interfaces. Instead, PROBE requires bidirectional connectivity 
between the probing interface and a proxy interface. The proxy 
interface can reside on the same node as the probed interface, or it 
can reside on a node to which the probed interface is directly 
connected. Section 5 of this document describes scenarios in which 
this characteristic is useful. 


Like PING, PROBE executes on a probing node. It sends an ICMP 
Extended Echo Request message from a local interface, called the 
probing interface, to a proxy interface. The proxy interface resides 
on a proxy node. 


The ICMP Extended Echo Request contains an ICMP Extension Structure 
and the ICMP Extension Structure contains an Interface Identification 
Object. The Interface Identification Object identifies the probed 
interface. The probed interface can reside on or directly connect to 
the proxy node. 


Bonica, et al. Standards Track [Page 3] 


RFC 8335 PROBE February 2018 


When the proxy interface receives the ICMP Extended Echo Request, the 
proxy node executes access control procedures. If access is granted, 
the proxy node determines the status of the probed interface and 
returns an ICMP Extended Echo Reply message. The ICMP Extended Echo 
Reply indicates the status of the probed interface. 


If the probed interface resides on the proxy node, PROBE determines 
the status of the probed interface as it would determine its oper- 
status [RFC7223]. If oper-status is equal to ’up’ (1), PROBE reports 
that the probed interface is active. Otherwise, PROBE reports that 
the probed interface is inactive. 


If the probed interface resides on a node that is directly connected 
to the proxy node, and the probed interface appears in the IPv4 
Address Resolution Protocol (ARP) table [RFC826] or IPv6 Neighbor 
Cache [RFC4861], PROBE reports interface reachability. Otherwise, 
PROBE reports that the table entry does not exist. 


1.1. Terminology 


This document uses the following terms: 


o Probing interface: The interface that sends the ICMP Extended Echo 
Request. 


o Probing node: The node upon which the probing interface resides. 


o Proxy interface: The interface to which the ICMP Extended Echo 
Request message is sent. 


o Proxy node: The node upon which the proxy interface resides. 

o Probed interface: The interface whose status is being queried. 

o Probed node: The node upon which the probed interface resides. If 
the proxy interface and the probed interface reside upon the same 


node, the proxy node is also the probed node. Otherwise, the 
proxy node is directly connected to the probed node. 


1.2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in BCP 
14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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ICMP Extended Echo Request 


The ICMP Extended Echo Request message is defined for both ICMPv4 and 
ICMPv6. Like any ICMP message, the ICMP Extended Echo Request 
message is encapsulated in an IP header. The ICMPv4 version of the 
Extended Echo Request message is encapsulated in an IPv4 header, 
while the ICMPv6 version is encapsulated in an IPv6 header. 


Figure 1 depicts the ICMP Extended Echo Request message. 
0 1 2 3 


OT 22° 3A E TT g 9 OD 23 A 56 EB 90 L 2 BAe 6 T 8g Q 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Code | Checksum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
| Identifier | Sequence Number | Reserved |L| 


+—t-F-4-4-4-4F-4-4-4-4F-4-4-4F-4F 4-4-4 -F -F-F -F FFF FF FHF tft 
| ICMP Extension Structure 


Figure 1: ICMP Extended Echo Request Message 
IP Header fields: 


o Source Address: The Source Address identifies the probing 
interface. It MUST be a valid IPv4 or IPv6 unicast address. 


o Destination Address: The Destination Address identifies the proxy 
interface. It MUST be a unicast address. 


ICMP fields: 


o Type: Extended Echo Request. The value for ICMPv4 is 42. The 
value for ICMPv6 is 160. 


o Code: MUST be set to 0 and MUST be ignored upon receipt. 
o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443. 


o Identifier: An Identifier to aid in matching Extended Echo Replies 
to Extended Echo Requests. May be 0. 


o Sequence Number: A Sequence Number to aid in matching Extended 
Echo Replies to Extended Echo Requests. May be 0. 


o Reserved: This field MUST be set to 0 and ignored upon receipt. 
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o L (local): The L-bit is set if the probed interface resides on the 
proxy node. The L-bit is clear if the probed interface is 
directly connected to the proxy node. 


o ICMP Extension Structure: The ICMP Extension Structure identifies 
the probed interface. 


Section 7 of [RFC4884] defines the ICMP Extension Structure. As per 
RFC 4884, the Extension Structure contains exactly one Extension 
Header followed by one or more objects. When applied to the ICMP 
Extended Echo Request message, the ICMP Extension Structure MUST 
contain exactly one instance of the Interface Identification Object 
(see Section 2.1). 


If the L-bit is set, the Interface Identification Object can identify 
the probed interface by name, index, or address. If the L-bit is 
clear, the Interface Identification Object MUST identify the probed 
interface by address. 


If the Interface Identification Object identifies the probed 
interface by address, that address can be a member of any address 
family. For example, an ICMPv4 Extended Echo Request message can 
carry an Interface Identification Object that identifies the probed 
interface by IPv4, IPv6, or IEEE 802 address. Likewise, an ICMPv6 
Extended Echo Request message can carry an Interface Identification 
Object that identifies the probed interface by IPv4, IPv6, or IEEE 
802 address. 


2.1. Interface Identification Object 


The Interface Identification Object identifies the probed interface 
by name, index, or address. Like any other ICMP Extension Object, it 
contains an Object Header and Object Payload. The Object Header 
contains the following fields: 


o Class-Num: Interface Identification Object. The value is 3. 

o C-Type: Values are (1) Identifies Interface by Name, (2) 
Identifies Interface by Index, and (3) Identifies Interface by 
Address. 


o Length: Length of the object, measured in octets, including the 
Object Header and Object Payload. 
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If the Interface Identification Object identifies the probed 
interface by name, the Object Payload MUST be the interface name as 


defined in [RFC7223]. If the Object Payload would not otherwise 
terminate on a 32-bit boundary, it MUST be padded with ASCII NULL 
characters. 


If the Interface Identification Object identifies the probed 
interface by index, the length is equal to 8 and the payload contains 
the if-index [RFC7223]. 


If the Interface Identification Object identifies the probed 
interface by address, the payload is as depicted in Figure 2. 


0 1 2 3 

On 1 20.3.4. e 7 89 OE 2 3 A 6 e DOL 2 3846: Be ONL 
+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| AFI | Address Length| Reserved 
+-+-+-+-+-+-+-+-+-+-+- ++ 
| Address 


Figure 2: Interface Identification Object - C-Type 3 Payload 
Payload fields are defined as follows: 


o Address Family Identifier (AFI): This 16-bit field identifies the 
type of address represented by the Address field. All values 
found in the IANA registry of Address Family Numbers (available 
from <https://www.iana.org/assignments/address-family-numbers>) 
are valid in this field. 


o Address Length: Number of significant bytes contained by the 
Address field. (The Address field contains significant bytes and 
padding bytes.) 


o Reserved: This field MUST be set to 0 and ignored upon receipt. 


o Address: This variable-length field represents an address 
associated with the probed interface. If the address field would 
not otherwise terminate on a 32-bit boundary, it MUST be padded 
with zeroes. 


3. ICMP Extended Echo Reply 


The ICMP Extended Echo Reply message is defined for both ICMPv4 and 
ICMPv6. Like any ICMP message, the ICMP Extended Echo Reply message 
is encapsulated in an IP header. The ICMPv4 version of the Extended 
Echo Reply message is encapsulated in an IPv4 header, while the 
ICMPv6 version is encapsulated in an IPv6 header. 
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Figure 3 depicts the ICMP Extended Echo Reply message. 


0 1 2 3 
0.2 2.3.4.9 6 7-8 90 12-34-56 7 89-0. L 2 34°96 7-8 9 OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Code | Checksum 
A E RFF mtr tata tata t tata tata tata tata E A a A 
| Identifier |Sequence Number|State|Res|A|4|6| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 3: ICMP Extended Echo Reply Message 


IP Header fields: 


(0) 


(0) 


Source Address: Copied from the Destination Address field of the 
invoking Extended Echo Request message. 


Destination Address: Copied from the Source Address field of the 
invoking Extended Echo Request message. 


ICMP fields: 


(0) 


Type: Extended Echo Reply. The value for ICMPv4 is 43. The value 
for ICMPv6 is 161. 


Code: Values are (0) No Error, (1) Malformed Query, (2) No Such 
Interface, (3) No Such Table Entry, and (4) Multiple Interfaces 
Satisfy Query. 


Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443. 


Identifier: Copied from the Identifier field of the invoking 
Extended Echo Request packet. 


Sequence Number: Copied from the Sequence Number field of the 
invoking Extended Echo Request packet. 


State: If Code is not equal to 0, this field MUST be set to 0 and 
ignored upon receipt. Likewise, if the probed interface resides 
upon the proxy node, this field MUST be set to 0 and ignored upon 
receipt. Otherwise, this field reflects the state of the ARP 
table or Neighbor Cache entry associated with the probed 
interface. Values are (0) Reserved, (1) Incomplete, (2) 
Reachable, (3) Stale, (4) Delay, (5) Probe, and (6) Failed. 


Res: This field MUST be set to 0 and ignored upon receipt. 
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4. 


o A (Active): The A-bit is set if the Code is equal to 0, the prob 
interface resides on the proxy node, and the probed interface is 
active. Otherwise, the A-bit is clear. 


o 4 (IPv4): The 4-bit is set if the A-bit is also set and IPv4 is 
running on the probed interface. Otherwise, the 4-bit is clear. 


o 6 (IPv6): The 6-bit is set if the A-bit is also set and IPv6 is 
running on the probed interface. Otherwise, the 6-bit is clear. 


ICMP Message Processing 


When a node receives an ICMP Extended Echo Request message and any 
the following conditions apply, the node MUST silently discard the 
incoming message: 


o The node does not recognize ICMP Extended Echo Request messages. 


o The node has not explicitly enabled ICMP Extended Echo 
functionality. 


o The incoming ICMP Extend Echo Request carries a Source Address 
that is not explicitly authorized for the L-bit setting of the 
incoming ICMP Extended Echo Request. 


o The incoming ICMP Extend Echo Request carries a Source Address 
that is not explicitly authorized for the incoming ICMP Extended 
Echo Request type (i.e., by ifName, by IfIndex, or by Address). 


o The Source Address of the incoming message is not a unicast 
address. 


o The Destination Address of the incoming message is a multicast 
address. 


Otherwise, when a node receives an ICMPv4 Extended Echo Request, it 
MUST format an ICMP Extended Echo Reply as follows: 


o Don’t Fragment (DF) flag is 1 
o More Fragments flag is 0 

o Fragment Offset is 0 

o TTL is 255 


o Protocol is ICMP 
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When a node receives an ICMPv6 Extended Echo Request, it MUST format 
an ICMPv6 Extended Echo Reply as follows: 


o Hop Limit is 255 
o Next Header is ICMPv6 
In either case, the responding node MUST do the following: 


o Copy the Source Address from the Extended Echo Request message to 
the Destination Address of the Extended Echo Reply. 


o Copy the Destination Address from the Extended Echo Request 
message to the Source Address of the Extended Echo Reply. 


o Set the DiffServ codepoint to CSO [RFC4594]. 
o Set the ICMP Type to Extended Echo Reply. 


o Copy the Identifier from the Extended Echo Request message to the 
Extended Echo Reply. 


o Copy the Sequence Number from the Extended Echo Request message to 
the Extended Echo Reply. 


o Set the Code field as described in Section 4.1. 

o Set the State field to 0. 

o Clear the A-bit, the 4-bit, and the 6-bit. 

o If (1) the Code Field is equal to (0) No Error, (2) the L-bit is 
set, and (3) the probed interface is active, set the A-bit. Also, 
set the 4-bit and the 6-bit as appropriate. 

o If the Code field is equal to (0) No Error and the L-bit is clear, 


then set the State field to reflect the state of the ARP table or 
Neighbor Cache entry that represents the probed interface. 


o Set the Checksum appropriately. 


o Forward the ICMP Extended Echo Reply to its destination. 
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4.1. Code Field Processing 


The Code field MUST be set to (1) Malformed Query if any of the 
following conditions apply: 


o The ICMP Extended Echo Request does not include an ICMP Extension 
Structure. 


o The ICMP Extension Structure does not include exactly one 
Interface Identification Object. 


o The L-bit is clear and the Interface Identification Object 
identifies the probed interface by ifName or ifIndex. 


o The query is otherwise malformed. 


The Code field MUST be set to (2) No Such Interface if the L-bit is 
set and the ICMP Extension Structure does not identify an interface 
that resides on the proxy node. 


The Code field MUST be set to (3) No Such Table Entry if the L-bit is 
clear and the address found in the Interface Identification Object 
does not appear in the IPv4 Address Resolution Protocol (ARP) table 
or the IPv6é Neighbor Cache. 


The Code field MUST be set to (4) Multiple Interfaces Satisfy Query 
if any of the following conditions apply: 


o The L-bit is set and the ICMP Extension Structure identifies more 
than one interface that resides in the proxy node. 


o The L-bit is clear and the address found in the Interface 
Identification Object maps to multiple IPv4 ARP or IPv6 Neighbor 
Cache entries. 


Otherwise, the Code field MUST be set to (0) No Error. 

5. Use Cases 
In the scenarios listed below, network operators can use PROBE to 
determine the status of a probed interface but cannot use PING for 
the same purpose. In all scenarios, assume bidirectional 
connectivity between the probing and proxy interfaces. However, 
bidirectional connectivity between the probing and probed interfaces 


is lacking. 


o The probed interface is unnumbered. 
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o The probing and probed interfaces are not directly connected to 
one another. The probed interface has an IPv6 link-local address 
but does not have a more globally scoped address. 


o The probing interface runs IPv4 only while the probed interface 


runs IPv6 only. 


o The probing interface runs IPv6 only while the probed interface 


runs IPv4 only. 


o For lack of a route, 


interface. 


6. Updates to RFC 4884 


the probing node cannot reach the probed 


Section 4.6 of [RFC4884] provides a list of extensible ICMP messages 
(i.e., messages that can carry the ICMP Extension Structure). This 


document adds the ICMP 


Extended Echo Request message and the ICMP 


Extended Echo Reply message to that list. 


7. IANA Considerations 
IANA has performed the 
o Added the following 
42 Extended Echo 


Added the following 
subregistry: 


(0) No Error 


o Added the following 


following actions: 
to the "ICMP Type Numbers" registry: 
Request 


to the "Type 42 - Extended Echo Request" 


to the "ICMPv6 ’type’ Numbers" registry: 


160 Extended Echo Request 


As ICMPv6 distinguishes between informational and error 
messages, and this is an informational message, the value has 
been assigned from the range 128-255. 


Added the following 
subregistry: 


(0) No Error 
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o Added the following to the "ICMP Type Numbers" registry: 
43 Extended Echo Reply 


Added the following to the "Type 43 - Extended Echo Reply" 
subregistry: 


(0) No Error 

(1) Malformed Query 

(2) No Such Interface 

(3) No Such Table Entry 

(4) Multiple Interfaces Satisfy Query 


o Added the following to the "ICMPv6 ’type’ Numbers" registry: 
161 Extended Echo Reply 


As ICMPv6 distinguishes between informational and error 
messages, and this is an informational message, the value has 
been assigned from the range 128-255. 


Added the following to the "Type 161 - Extended Echo Reply" 
subregistry: 


(0) No Error 

(1) Malformed Query 

(2) No Such Interface 

(3) No Such Table Entry 

(4) Multiple Interfaces Satisfy Query 


o Added the following to the "ICMP Extension Object Classes and 
Class Sub-types" registry: 


(3) Interface Identification Object 


Added the following C-types to the "Sub-types - Class 3 - 
Interface Identification Object" subregistry: 


(0) Reserved 

(1) Identifies Interface by Name 
(2) Identifies Interface by Index 
(3) Identifies Interface by Address 


C-Type values are assigned on a First Come First Serve (FCFS) 
basis with a range of 0-255. 


All codes mentioned above are assigned on an FCFS basis with a range 
f- 0=255% 
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8. 


Security Considerations 
The following are legitimate uses of PROBE: 
o to determine the operational status of an interface. 


o to determine which protocols (e.g., IPv4 or IPv6) are active on an 
interface. 


However, malicious parties can use PROBE to obtain additional 
information. For example, a malicious party can use PROBE to 
discover interface names. Having discovered an interface name, the 
malicious party may be able to infer additional information. 
Additional information may include: 


o interface bandwidth 


o the type of device that supports the interface (e.g., vendor 
identity) 


o the operating system version that the above-mentioned device 
executes 


Understanding this risk, network operators establish policies that 
restrict access to ICMP Extended Echo functionality. In order to 
enforce these policies, nodes that support ICMP Extended Echo 
functionality MUST support the following configuration options: 


o Enable/disable ICMP Extended Echo functionality. By default, ICMP 
Extend Echo functionality is disabled. 


o Define enabled L-bit settings. By default, the option to set the 
L-bit is enabled and the option to clear the L-bit is disabled. 


o Define enabled query types (i.e., by name, by index, or by 
address); by default, all query types are disabled. 


o For each enabled query type, define the prefixes from which ICMP 
Extended Echo Request messages are permitted. 


o For each interface, determine whether ICMP Echo Request messages 
are accepted. 


When a node receives an ICMP Extended Echo Request message that it is 
not configured to support, it MUST silently discard the message. See 
Section 4 for details. 
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PROBE must not leak information about one Virtual Private Network 
(VPN) into another. Therefore, when a node receives an ICMP Extended 
Echo Request and the proxy interface is in a different VPN than the 
probed interface, the node MUST return an ICMP Extended Echo Reply 
with error code equal to (2) No Such Interface. 


In order to protect local resources, implementations SHOULD rate- 
limit incoming ICMP Extended Echo Request messages. 
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Appendix A. The PROBE Application 


The PROBE application accepts input parameters, sets a counter, and 
enters a loop to be exited when the counter is equal to 0. On each 
iteration of the loop, PROBE emits an ICMP Extended Echo Request, 
decrements the counter, sets a timer, and waits. The ICMP Extended 
Echo Request includes an Identifier and a Sequence Number. 


If an ICMP Extended Echo Reply carrying the same Identifier and 
Sequence Number arrives, PROBE relays information returned by that 
message to its user. However, on each iteration of the loop, PROBE 
waits for the timer to expire regardless of whether an Extended Echo 
Reply message arrives. 


PROBE accepts the following parameters: 

o Count 

o Wait 

o Probing Interface Address 

o Hop Count 

o Proxy Interface Address 

o Local 

o Probed Interface Identifier 

Count is a positive integer whose default value is 3. Count 
determines the number of times that PROBE iterates through the above- 
mentioned loop. 

Wait is a positive integer whose minimum and default values are 1. 


Wait determines the duration of the above-mentioned timer, measured 
in seconds. 


Probing Interface Address specifies the Source Address of the ICMP 
Extended Echo Request. The Probing Interface Address MUST be a 
unicast address and MUST identify an interface that resides on the 
probing node. 


The Proxy Interface Address identifies the interface to which the 
ICMP Extended Echo Request message is sent. It must be an IPv4 or 
IPv6 unicast address. If it is an IPv4 address, PROBE emits an 
ICMPv4 message. If it is an IPv6 address, PROBE emits an ICMPv6 
message. 
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Local is a boolean value. It is TRUE if the proxy and probed 
interfaces both reside on the same node. Otherwise, it is FALSE. 


The Probed Interface Identifier identifies the probed interface. It 
is one of the following: 


(0) an interface name; 


o an address from any address family (e.g., IPv4, IPv6, IEEE 802, 
48-bit MAC, or 64-bit MAC); or 


o an if-index. 


If the Probed Interface Identifier is an address, it does not need to 
be of the same address family as the proxy interface address. For 
example, PROBE accepts an IPv4 Proxy Interface Address and an IPv6 
Probed Interface Identifier. 
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